home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
HAM Radio 3.2
/
Ham Radio Version 3.2 (Chestnut CD-ROMs)(1993).ISO
/
tcp
/
ax25
/
ax25.doc
< prev
next >
Wrap
Text File
|
1992-04-22
|
7KB
|
151 lines
AX25 driver for BAYCOM-like modem.
Beta version + minor corrections, 21th of April 1992
Free license is granted for _amateur_ use only.
AX25.COM is a packet driver comforming (to some extend) to well known
"FTP packet driver" specification. It's purpose is to serve as interface
between application software (e.g. KA9Q NOS) and a modem connected
to RS232 port (e.g. BAYCOM modem).
The driver relies on the following RS232 pins:
RTS - controls PTT: high level enables the transmitter
DTR - transmitted data. On this pin the driver sends data
to be transmitted by the modem.
When in receive state this pin is held high.
CTS - received data. The modem should supply here the data it receives.
DCD - the modem may supply here "carrier detect" signal.
This pin is _optional_ - it is not a must because the driver
is able to deliver carrier signal from received data.
GND - a common ground for the above signals.
TxD outputs a signal which is in high (positive voltage)
most of the time. A low power modem (TCM3105) can be supplied
from RTS+DTR+TxD (adding realized with diodes).
My primary intention while writting this driver was to provide
opportunity to run KA9Q NOS with simple modems based on TCM3105
or AM7910 chip. I tested the driver with NOS - no other software
was available at the time. The driver can as well be examined
by PKSTAT.COM and terminated (removed from memory) by TERMIN.COM.
These two utilities are part of packet drivers package from Clarkson.
AX25 driver heavily relies on quick interrupt response.
Thus the application software should avoid disabling
CPU interrupts for long periods. Or say it in another words:
enable interrupts whenever possible.
AX25.COM has several start-time options. To see them start it
with "-?". If you start the driver without any command line
switch it will use default values: COM1, 1200 baud, etc.
These are the options - default values are in []:
-b<bit rate> [1200] - decimal number
defines the bit rate. Rates below 300 are not accepted
because of PC's timer specific features.
I didn't put any upper limit here because it really depends on your CPU...
Please specify here rates which can be represent in form 14400/n
If you don't the driver will adjust the baud rate to match this condition.
Examples: 1800 = 14400/8, 1200 = 14400/12, 300 = 14400/48
-i<software interrupt> [60] - hexadecimal number
Tells the driver which software interrupt to use
for control functions. Usually you would use numbers
from 60..63 here because these are intended for user applications.
-B<COM port I/O base> [3f8] - hexadecimal number
I/O address of RS232 port: 3f8 for COM1, 2f8 for COM2
-I<COM port IRQ> [4] - hexadecimal number
Interrupt request line of RS232 port: 4 for COM1, 3 for COM2
Only the range 2..7 is supported so far. I'm not even sure the irq 2
would work...
-s<slot time> [64] - decimal number
Slot time for p-persistance scheme. The value is in data bits.
For 1200 baud, slot time 120 bits means 100 ms.
-p<persistance> [20] - decimal number 0..255
p-persistance - the higher the value the higher the probability
of activating PTT at each time slot.
Your station becomes more "agressive" on the air with
increasing persistance and decreasing slot time.
-h<tx header length> [500] - decimal number 8..65535
Number of extra bits the transmitter sends before actuall data
is transmitted.
You should always make this number as small as possible
for best bandwidth use. 500 tells you basicaly that 500 _useless_
bits (60 bytes) are being transmitted before real packet data goes in.
Unlike most TNCs this driver sends a square wave not a series
of HDLC flags in front of a packet. This was easier to program
in software and it makes DPLL lock faster at receiving end.
Thus less header bits should be needed...
-t<tx tail length> [16] - decimal number 8..65535
Number of extra bits the transmitter sends _after_ the actuall data.
-c<carrier sense mode> [t] - one of the following letters: f,c,t,d
mode meaning
f full duplex - transmit whenever data is pending
c sense modem DCD line to find out whether channel is busy.
Your modem hes to supply this signal. Note that TCM3105
does not do it very well... it sets DCD to high on any noise
on audio input.
t sense data transition - if incoming data signal moves
the driver assumes that the channel is busy - BAYCOM uses
the same (or very similar) way up to version 1.4
d deliver "channel busy" status by analysing incoming data.
BAYCOM v1.5 does effectively similar thing although
it uses different algorithm.
With this mode you may run your radio with squelch open
all the time.
Please note that argument line is case sensitive and so are hexadecimal
values... "2F8" will not do - you must specify "2f8".
Getting started quickly:
1. Start the ax25.com - most important parameters are COM base and irq.
e.g. for COM1: ax25 -B3f8 -I4
2. Start KA9Q NOS.
type in:
attach packet 0x60 ax25 5 512
trace ax25 111
you should see packets being received now...
3. Try to connect to another station by typing:
connect ax25 <callsign>
If you realized that you started ax25.com with not the parameters
you liked use termin.com to terminate the driver (e.g. termin 0x60)
and start ax25.com again with another option set.
How big packets can ax25 driver handle ?
The receiver can handle 1024 byte (including CRC) frames.
For the transmitter this parameter is not well defined
because it's buffer stores periods between data transitions
not the bytes directly. For worst case packet containing
all zeros the limit is 1020 bytes (for best case it is 6K).
If there are requests for larger buffers I can make them
straight away but then more resident memory will be occupied
by the driver. Now it needs about 12K - for buffers twice
as big it would need 9K more.
Have fun and _please_ send comments/hints/complaints to:
jalocha@chopin.ifj.edu.pl
or jalocha@vxcern.cern.ch
or jalocha@priam.cern.ch
Pawel Jalocha
Rynek Kleparski 14/4a
PL-31150 KRAKOW (Poland)